@nschonni You're right that schedule only runs on the default branch, but workflow_dispatch can be triggered on a selected ref (branch/tag). This may lead to executing repo scripts from a non-main ref in a context where secrets are available, so extending the if guard to main could be a sensible security step.

By the way, with workflow_dispatch added, this workflow would also be runnable manually alongside the existing schedule. Adding concurrency could help prevent overlapping runs racing on the same updates (e.g., duplicate PRs or conflicting pushes).

concurrency:
  group: automatic-updates
  cancel-in-progress: false

The workflow is supposed to run every 15 minutes:

In practice it seems that GitHub Actions is throttling the frequency or dropping queued jobs.

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule says:

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.

So it would be convenient to have a workflow_dispatch trigger here for occasions like now when you know there is a release pending, including musl build availability, and the the workflow has not picked it up yet.

Actually I just realized that isn't necessary, since you can just re-run a previous job. (I just did that.)

@nschonni / @SimenB

I've actually used re-running a previous job on the automatic-updates.yml workflow lately, and it seems to work quite well to speed up the process when GitHub isn't scheduling the cron jobs the way they're specified.

Could we just close this PR or is there something really missing that this PR would cover?